Tracking the identity of a network packet as it traverses a boundary can be difficult due to the design of an Internet Protocol (IP) network. A boundary can include routers, proxies, gateways, firewalls, and other types of computer network components. While IP calls for a source and destination address within network packets, there is no provision authenticating the origin of a packet. Further complicating matters is an Internet Engineering Task Force standard known as Network Address Translation (NAT), which can allow multiple nodes on a network to share an IP address. NAT was originally introduced as a means to continue the Internet's growth despite rapid depletion of the IPv4 address space, and its ancillary intent was to hide a network's internal topology and architecture from the world by 1) using unique, discrete address spaces for both the internal and external network segments as well as 2) mediating all inbound and outbound communications between those segments. When NAT is implemented, the source address of a packet changes from the original sender of the packet to the address of the boundary performing NAT.
NAT is typically performed on boundaries that sit in the path of communication between a client and server. Boundaries can intercept and relay the client's request to the server as well as the server's response to the client. Therefore, while client requests are sourced from the client, boundary requests alter the original client requests to appear from the boundary. Likewise, server responses are addressed to the boundary, whereas boundary responses are altered to appear addressed directly to the client. The boundary alters the source IP address, the source application ports and their associated checksums within each packet header.
Accordingly, a need remains in the art to develop a system and method to determine the identity of network packets as they traverse boundaries that perform NAT.